home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1997 July / EnigmA AMIGA RUN 20 (1997)(G.R. Edizioni)(IT)[!][issue 1997-07 & 08][EAR-CD IV].iso / lightwave / lwmlist / 96.lightwave-0115 / 000078_lightwave@garcia.com _Tue Jan 16 02:06:42 1996.msg < prev    next >
Internet Message Format  |  1996-01-21  |  2KB
  1. Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by keeper.albany.net (8.7.1/8.7.1) with ESMTP id CAA05323 for <dwarner@albany.net>; Tue, 16 Jan 1996 02:06:41 -0500 (EST)
  2. Received: from garcia.com by relay4.UU.NET with SMTP 
  3.     id QQzyso24627; Tue, 16 Jan 1996 01:34:07 -0500 (EST)
  4. Received: from  (localhost) by garcia.com (5.x/SMI-SVR4)
  5.     id AA19209; Tue, 16 Jan 1996 01:34:25 -0500
  6. Date: Tue, 16 Jan 1996 01:34:25 -0500
  7. Errors-To: dwarner@albany.net
  8. Message-Id: <Pine.SUN.3.91.960116003059.22974B-100000@access4.digex.net>
  9. Errors-To: dwarner@albany.net
  10. Reply-To: lightwave@garcia.com
  11. Originator: lightwave@garcia.com
  12. Sender: lightwave@garcia.com
  13. Precedence: bulk
  14. From: Ernie Wright <erniew@access.digex.net>
  15. To: Multiple recipients of list <lightwave@garcia.com>
  16. Subject: Re: Lightwave Rev C renders 250% faster - why?
  17. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
  18. Status: RO
  19. X-Status: 
  20.  
  21. --------
  22. Q:  I assume the 200-300% increase is only geared towards certain
  23.     functions and not the actual speed increase in rendering, correct?
  24.  
  25. A:  No, it's a rendering increase. But that much of a speed increase
  26.     is only while performing certain rendering functions.  For example
  27.     the Blade scene. It used to take FOREVER compared to NT. 95 didn't
  28.     seem to like things such as shadow maps and lens flares.
  29. --------
  30.  
  31. This should be clarified.  The LW GUI (as opposed to ScreamerNet) has
  32. to listen for events (e.g. the Esc key, timer updates) while rendering.
  33. The speed-up was accomplished in the event handling code.  This should
  34. shed light on why SN has been running so much faster than the GUI under
  35. 95.  The speed difference between the two is as unmistakable a clue as 
  36. you'll ever see in program optimization--the problem *had* to be with
  37. something that SN didn't do.
  38.  
  39. Some rendering functions seem to be affected more than others, but this
  40. just reflects variations in the frequency with which different functions
  41. pause to handle events.  In other words, the "problem" functions were 
  42. checking for events, and using slow event code, more frequently.
  43.  
  44. - Ernie